Platform independent and non-invasive financial report mark-up

ABSTRACT

Platform independent and non-invasive financial report mark-up. The invention provides an enterprise-scale, non-invasive report mark-up system that gives substantially non-invasive approach to applications, processes and existing databases of the legacy system environment. The invention is operable to allow transition from the legacy system environment using one currency to another currency such as to the EURO over time. The invention allows for a number of operations without manual restatement, reconciliation or use of parallel systems; it also provides for access to timely information and electronic reporting of financial documents with substantial cost savings, thereby meeting the rapid response requirements necessitated by the continued emergence of e-commerce activities. A middleware layer that interfaces two layers that may be viewed as a legacy system environment and a client environment, such as a browser based Internet or other user environment, without the need for significant custom interface code between unique applications or environments.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application is based on and claims priority to U.S.Provisional Patent Application Ser. No. 60/177,333 entitled “SYSTEM ANDMETHOD FOR IMPLEMENTING EURO TRANSITION REQUIREMENTS,” (Attorney DocketNo. PR1036), filed Jan. 21, 2000.

[0002] The present application is also based on and claims priority toU.S. Provisional Patent Application Ser. No. 60/242,510 entitled“PLATFORM INDEPENDENT AND NON-INVASIVE REPORT MARK-UP,” (Attorney DocketNo. 00R2E101P), filed Oct. 23, 2000.

[0003] All of such applications are hereby incorporated herein byreference in their entirety, including any drawings and appendices, andis made part of the present U.S. Patent Application for all purposes.

BACKGROUND

[0004] 1. Technical Field

[0005] The present invention relates generally to report mark-up; and,more particularly, it relates to platform independent and non-invasivefinancial report mark-up.

[0006] 2. Related Art

[0007] Twelve European countries are currently in transition fromNational Currency Units (NCU) to a single European currency, the EURO.There is great difficulty in converting to the EURO, and from anenterprise perspective the impacts to information technology (IT)systems are significant. One of the difficulties stems from the factthat the temporary transition phase requirements of the legacy currency(NCU) must co-exist with the new EURO during a certain period of time.There is no simple or easy overnight conversion from one currency toanother under the currently proposed transitions schemes, andenterprises must deal with the problem of how to get useful informationfor users and systems that will enable them to operate in the newcurrency going forward.

[0008] During the transition period, which lasts from Dec. 1, 1999 toJun. 30, 2002, the European Union has mandated numerous technicalrequirements relating to triangulation, permissible rounding errors,auditability, introduction of six significant digits, decimalization andother items which control the process but which cause very significantimpacts to IT systems. It is the temporary requirements of transitionthat add most of the costs, and consultants have claimed that in manycases EURO IT impacts will exceed the scope of Y2K. When all this workhas been accomplished, business will continue as before except that itwill operate in EURO. No lasting competitive advantage will have beenconferred.

[0009] Traditional approaches to solve this problem are in fact similarto Y2K, and most of them involve renovation of databases, which is aprocess that is highly invasive to the legacy system environment.Renovation converts the contents of the legacy databases from onecurrency to another, typically requiring field expansion and dealingwith hard-coded entries and tables. Inevitably, unintended conversionerrors will be introduced, and the change of currencies also impacts theaudit trail since source documentation no longer matches the database.The effectiveness of techniques like scanning that improve productivityare limited by hard coding of fields and tables and other problems inthe original code, since it was not designed to accommodate suchchanges. Further, if historical data must be converted manually in thedatabases, then a separate parallel system of historical data must bemaintained for archiving purposes.

[0010] Large enterprises may have 200 or more legacy systems that areimpacted by the change to a single European currency. The approachuniversally used is to apply a “wrapper” to the application or database,then to “renovate” the underlying database, and to do this uniquely toeach and every system. The limitations of such a strategy are many innumber. Examples of such limitations include the following: such changesare highly invasive to the legacy systems and introduce inevitableerrors; legacy audit documentation no longer matches the convertedcurrency; time to plan and execute are lengthy; and cost and resourceavailability can be prohibitive. Further, this work adds no lastingbusiness value for the time and effort invested.

[0011] All of the conventional, proposed solutions work to fix atemporary problem, so that most of this functionality which isimplemented on virtually every enterprise system that deals withfinancial data will be turned off or “thrown away” at the end of theco-existence or transition period between the national currencies andthe EURO. Obviously, implementing these solutions on a system by systembasis is extremely costly, risky, and time consuming, and addsdependence upon expensive outside contractors.

[0012] Further limitations and disadvantages of conventional andtraditional systems will become apparent to one of skill in the artthrough comparison of such systems with the present invention as setforth in the remainder of the present application with reference to thedrawings.

SUMMARY OF THE INVENTION

[0013] Various aspects of the present invention can be found in anenterprise-scale non-invasive financial report mark-up processingsystem. The system includes a legacy system that is operable to generatestructured legacy system information having a format and havingfinancial data corresponding to a first currency standard and amiddle-ware application layer, communicatively coupled to the legacysystem, that is operable to receive the legacy system report from thelegacy system via electronic printing thereby generating a legacy systeme-report. The middle-ware application layer employs a profile to performmark-up processing on selected portions of the legacy system e-report togenerate a modified legacy system e-report, and the modified sourcee-report comprising financial data corresponding to a second currencystandard.

[0014] In certain embodiments of the invention, the second currencystandard includes a EURO currency. The middle-ware application layer mayalso include a burster, and the burster may also include the profile.The burster is operable to parse the legacy system e-report a number ofsub-e-reports or a number of sub-portions. The at least one additionallegacy system is operable to generate at least one additional legacysystem report having at least one additional format and having financialdata corresponding to a third currency standard. The middle-wareapplication layer is also communicatively coupled to the at least oneadditional legacy system and is operable to receive the at least oneadditional legacy system report from the at least one additional legacysystem via electronic printing thereby generating at least oneadditional legacy system e-report. The middle-ware application layeremploys at least one additional profile to perform mark-up processing onselected portions of the at least one additional legacy system e-reportto generate at least one additional modified legacy system e-report. Themodified source e-report includes financial data corresponding to afourth currency standard. The profile and the at least one additionalprofile are substantially a common profile. The second currency standardand the fourth currency standard both include a common currencystandard. The modified legacy system e-report is generated during apredetermined transition period from the first currency standard to thesecond currency standard.

[0015] Other aspects of the present invention can be found in anenterprise-scale non-invasive financial report mark-up processingsystem. The system includes a legacy system that is operable to generatea source report having financial information based on a nationalcurrency, a middle-ware application layer, communicatively coupled tothe legacy system, that is operable to receive an electronically printedversion of the source report and perform non-invasive mark-up processingof the financial information based on the national currency within thesource report and to convert that financial information to financialinformation based on the EURO thereby generating a target report, and auser system, communicatively coupled to the middle-ware applicationlayer, that is operable to retrieve the target report from themiddle-ware application layer.

[0016] In certain embodiments of the invention, the at least one of thecommunicative coupling between the legacy system and the middle-wareapplication layer and the communicative coupling between the middle-wareapplication layer and the user system includes communicative couplingvia the Internet. Other communicatively coupling, including intranet andextranet delivery are also included. The electronically printed versionof the source report is generated based on an e-print profile. Thenon-invasive mark-up processing is performed using a profile having anumber of processing rules, and the profile is contained within themiddle-ware application layer. The middle-ware application layerdistributes the target to at least one additional user system. Themiddle-ware application layer distributes the target to the user systemafter the user system transmits a request to the middle-ware applicationlayer. The middle-ware application layer may also include a burster, andthe burster may also include a profile.

[0017] Yet even other aspects of the present invention can be found in amethod to perform non-invasive financial report mark-up processing. Themethod includes creating a source report profile to be used to process asource report where the source report includes financial datacorresponding to a first currency standard, electronically transmittingthe source report to a middle-ware application layer, processing thesource report within the middle-ware application layer to generate atarget report based on the report profile, and generating a modifiedsource report where the modified source report includes financial datacorresponding to a second currency standard.

[0018] In certain embodiments of the invention, the second currencystandard includes a EURO currency. The target report is generated inresponse to a request provided by a user system. The target reportincludes a number of sub-portions. The target report may also be parsedinto a number of sub-e-reports.

[0019] Other aspects, advantages and novel features of the presentinvention will become apparent from the following detailed descriptionof the invention when considered in conjunction with the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] A better understanding of the present invention can be obtainedwhen the following detailed description of various exemplary embodimentsis considered in conjunction with the following drawings.

[0021]FIG. 1 is a system diagram of an enterprise-scale, non-invasivereport mark-up system built in accordance with the present invention.

[0022]FIG. 2 is a functional block diagram illustrating an embodiment ofa method performed in accordance with the present invention.

[0023]FIG. 3 is a system diagram illustrating an embodiment of reportprocessing performed in accordance with the present invention.

[0024]FIG. 4 is a system diagram illustrating another embodiment ofreport processing performed in accordance with the present invention.

[0025]FIG. 5 is a system diagram illustrating an embodiment of profileprocessing performed in accordance with the present invention.

[0026]FIG. 6 is a system diagram illustrating another embodiment ofprofile processing performed in accordance with the present invention.

[0027]FIG. 7 is a system diagram illustrating another embodiment ofprofile processing performed in accordance with the present invention.

[0028]FIG. 8 is a timeline diagram illustrating an embodiment ofcurrency conversion that is capable to be performed in accordance withthe present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0029] The current and future transition efforts of European nations toconvert to the EURO offer an opportunity to apply emerging reportingtechnologies to this problem as a new paradigm in an unconventionalmanner not yet been seen in the marketplace after two years oftransition.

[0030] In the existing emerging report technologies, an alternative doesnot exist that can operate at an enterprise scale to quickly implementthis change in a flexible, fast, and scalable manner at lower cost whileleaving behind a platform that is operable to add business value in thefuture.

[0031] The present invention is operable to provide an alternative tothe use of wrappers and database renovation that are widely used inEurope to implement the transition to the EURO currency. By so doing, itis possible to substantially reduce the time and cost associated withhistorical data usage after EURO becomes the single currency, whileadding business value in the form of retained information technologyinfrastructure that acts as a platform to provide instant e- access toenterprise information.

[0032] One critical choice that many enterprises face is whether toconvert historical data using expensive techniques, or to leverage thatdata in a non-invasive way that cost effectively and quickly providesconverted information to anyone in the information who has a need toknow, at any time, anywhere. Until now, enterprises have performed thishistorical database renovation as an assumed part of the EURO conversioneffort. This effort has three distinct parts in reality. They include 1)a transition, where the enterprise appears to the outside world to beoperating in EURO; 2) a conversion, where the enterprise convertshistorical data in the databases to EURO; and 3) a migration, where alldata entering the database in entered in EURO going forward. Traditionhas held all three must occur as a big bang. Using certain aspects ofthe present invention, the historical data conversion can also behandled using the present invention, thereby obtaining some of thebenefits outlined in this patent application.

[0033] The present invention provides a solution that contains a numberof characteristics, some of which are enumerated below.

[0034] Non-invasive. The present invention is non-invasive to legacydatabases to avoid the effort to restate and reconcile the entries andpreclude creation of coding errors. The legacy environment is left intact. This provides other advantages in terms of efficiency. The use ofbusiness rules allows for different currencies to co-exist in a singledatabase without pollution.

[0035] Platform independent. Many environments of large enterprises haveliterally hundreds of systems. Solutions are hardware and softwareplatform independent to speed rollout and add scalability to thesolution.

[0036] Maintain auditability. The present invention is operable tomaintain the audit trail by leaving the legacy financial data in thesame currency as paper documentation. Indeed, any changes or conversionsoutside the legacy environment are contained in an audit log.

[0037] Enterprise scale. Changes outside the legacy systems arecentrally managed on an enterprise scale. The present invention supportsrollout to one system or many.

[0038] Improved Speed, Flexibility and Control. The present invention isinherently more flexible to accommodate change quickly across theenterprise, which may have literally hundreds of systems. It hasinherent advantages of improved control and can be implemented withgreat speed. Implementation can literally be reduced from many months toweeks, using trained internal resources, at substantial savings.

[0039] Support for Interoperability. Such a solution is required tosupport the interoperability of solutions where some may have beenupdated by vendors and may require converted input from systems that areupdated using this invention.

[0040] Phased Implementation. Some systems may have been updated byvendors, or systems or clusters of related systems may be upgraded atdifferent times. This process is called a phased implementation andallows interoperability for transformed data to be shared across theenterprise in a productive and efficient manner.

[0041] Reduce Archiving and Storage. The present invention is operableto reduce the storage and archiving needed to deal with a converted andunconverted databases. Indeed, the solution itself may be viewed asactually being the archive solution for converted data.

[0042] Rounding Error Detection and Correction. The present invention isoperable to detect and correct the occurrence of rounding errorspermitted and inevitable under the regulations;

[0043] Reduced training and external support. The present invention isoperable to leave the legacy systems in tact means that existing staffcan be retained, and can be trained in highly productive new tools,thereby reducing dependence on outside support and speedingimplementation. This and the use of browsers also reduce trainingrequirements.

[0044] Add Competitive Advantage. The ideal solution would NOT bethrowaway work, but would retain value when the project is complete. Thepresent invention actually adds lasting value to the legacy environmentby adding a number of new features that add significant value. Forexample, competitive advantage is added by the acceleration in thevelocity of information that can be made available from enterpriseinformation stores. Further, the architecture of the solution offered bythe present invention provides the opportunity to implement it remotelyfrom the databases, so that it may be implemented using an ASP(Application Service Provider) business model, thereby even furtherreducing costs and increasing benefits.

[0045] Other Characteristics. The present invention offers othercharacteristics in various embodiments of the invention, many of whichare more readily understood in the various embodiments described above.

[0046] One aspect of the present invention is the realization that theoptimal implementation of unique enterprise requirements for temporarytransition phase requirements is to isolate them from the legacy andclient environments. These functions and features described in detailbelow have been aggregated in a middleware layer, between the existinglegacy system environment 12 and the Browser Based Internet UserEnvironment 14 shown in FIG. 1.

[0047]FIG. 1 is a system diagram of a middleware layer implementation 5built in accordance with the present invention. The middleware layerimplementation 5 is operable to support and perform the temporary andunique requirements of the EURO Conversion Transition Period.

[0048] The term “middleware” in this case describes the fact that theapplication simply “snaps” into place between two layers, a legacysystem environment 12 and a client environment 14, sometimes referred toas a browser based Internet user environment 14, without the need for alot of custom interface code between unique applications orenvironments. Other network interfaces in addition to the Internet arealso included within the scope and spirit of the invention. In one case,the invention utilizes a Microsoft NT based Web Application Server asits core platform to host the necessary functionality.

[0049] The present invention fully recognizes the massive investmentsmade by enterprises in collecting, storing and managing data, and inproviding it in the form of useful information to communities of usersand individuals. The extraction of information from data and its timelyand secure provision to individuals who have need to know is what givesdata value in an enterprise. The Internet has accelerated the velocityof information, and has made it a competitive necessity to getinformation into the hands of knowledge workers whenever and whereverthey need it. No other solution to this problem addresses this criticalbackground requirement, and this is where the invention leaves lastingvalue behind after EURO is a reality. For example, the present inventionis operable to perform relationship management within a company orenterprise to allow many users to share and use common informationeasily and cost-effectively.

[0050] The present invention recognizes that value is derived from datain enterprise applications principally in the form of reports. Forexample, databases provide value to an enterprise by providinginformation principally in the form of reports to users. Information canalso be accessed from the database in the form or reports to be used asinput to other systems as well. This feature supports interoperabilityand phased implementation of the various systems mentioned above.

[0051] This invention recognizes that development of custom interfacesoftware for unique hardware and software products and environments iscostly and limits system flexibility. Instead of implementing aplatform-dependent methodology, the invention instead relies on the useof standard report formats to capture data from a database. Legacysystems either have the necessary utilities, or they can be purchasedfor a modest cost, to allow the legacy systems to transfer fileselectronically using standard formats. In this way the invention is madeplatform independent, which helps enable it to scale from one to manyplatforms.

[0052] From one perspective, the functional operation of the presentinvention is described below. Files are transferred automatically on ascheduled basis from legacy systems into the Report Portalfunctionality. Legacy systems have their own report writers andadministrators, who use them to create valuable information. Today, manysuch structured reports are still distributed on paper, and many largereports have difficulty being processed. The invention leverages someexisting technology to capture these reports electronically, and thenuses sophisticated techniques to manage the secure electronicdistribution and storage of them to enterprise users with a need for theinformation.

[0053] This provides a platform to enable required EURO functionalitywithout the need for invasive procedures. It has the effect of providingan e-business infrastructure platform that can stay in place and beextended beyond the EURO timeframe and application, while providing acompetitive advantage by giving instantaneous information to users whohave immediate need for it. Significantly, it obviates the need forrenovation, restatement and reconciliation of databases and the need toovercome various limitations inherent in legacy construction that didnot envision the need for EURO conversion. Examples include hard codingfields, values and tables as well as limitations in field structure,labeling, etc.

Use of the Report Profile

[0054] The invention requires that a Report Profile be made for eachreport that is electronically captured, managed, distributed and stored.The term reports, as used herein, can also refer to screens that arerepresentative of or reports and queries that initiate the generation ofreports. Both of which are essentially structured real-time reports.Either of these reports can be profiled in various embodiments of theinvention within departing from the scope and spirit thereof.

[0055] When a legacy application transfers a report file to the reportportal, a report profile will be created. The profile is associated witha specific source report but operates independently of the data in aspecific version of the report. In this way the report is executedaccording to the profile, independent of changes in data for thatreport. It is significant that every time thereafter that this report isrun, the system will automatically look for its associated profile. Thesystem matches the profile to its associated report and automaticallyexecutes the profile, without further human intervention in a“lights-out” enterprise manner. New reports require new profiles.

[0056] This profile typically deals with source and target reportformats, which users will have access to the report, whether it is sentby email or in a complete attachment, security provisions, how manyversions will be stored and for how long, who has change control overthe report, and similar matters. However, the invention extends theReport Profiling process by recognizing that apart from the reportobject and related meta-data, there is actual live data in the reportstream that can be captured and used for other purposes.

Use of the Burster

[0057] The Burster is a powerful tool that essentially enables the userto break up any size report into pieces that can then be distributed orcustomized according to the specific needs of the business. It isanalogous to what a person would do in separating pages from a paperreport so that specific pieces can be given to specific individuals. TheBurster does this electronically, and has the ability to implement manymore sophisticated functions.

[0058] In one embodiment, the mark up functions used by the presentinvention are incorporated into the Burster. This allows access to thereport's live data stream. However, this is not necessary in otherembodiments, and other methods may be used as well by those skilled inthe art. The system then calls on specific functionality created forthis purpose to make the various changes needed to implement EUROfunctions on specific reports in the enterprise environment. In thisway, it is possible to automate the generation of EURO data from legacycurrency reports to be used by individuals and even systems that requireEURO input data streams. Parsing using a Burster is a desirablefunctionality within certain embodiments of the present invention.

Report Mark-up

[0059] For cases requiring currency conversion, and many other cases aswell, the profile is adapted to grab the live data stream. It then usesspecial “mark-up” features to call specific functions that are requiredto convert a given source report in legacy currency into a target reportwith the necessary information in Euros. The mark-up features areimplemented in intuitive graphical tools and drop-down menus. The systemautomatically generates script to execute the selected functionalities,although unique code can be written, if desired, by a capable user.Conversion macros for desktop systems are available and can be adaptedfor use in the present invention.

[0060] The profile allows the Administrator to select the desired targetreport format, so that the source report can be given additionalfunctionalities such as export to Excel, creation of various filters, oruse of PDF functionalities. All manner of unique EURO functionalitiesare provided, including conversion rates, source currency, targetcurrency, rounding error detection and correction, various decimalselections and the like. Unique functionalities described later in thisapplication include date-driven and source-driven criteria from thereport to enable various special features. These features aresignificant in that they address the need to avoid ‘pollution’ of thedatabase by providing safeguards that allow multiple currencies toco-exist.

[0061] Mark up functions include automation aides to speed the mark upof large reports. Numerous such aides will be apparent to those trainedin the art, and they would include techniques to exclude certain rows,columns or cells before a general report conversion, or other techniquesto replicate a step or function. Techniques to include automaticcomments, tool tips or annotations, as well as hyperlinking to usefulderived and related documents would also be helpful and are includedwithin the scope and spirit of the invention. Mark up functions includedrop down menus, graphical tools, and automatic generation of code. Markup functionality is critical to the support of a phased implementationfor Euro, where the invention creates EURO data in the report layer anduses it to feed another application that has been independently upgradedto Euro, perhaps by a vendor.

User Presentation

[0062] The present invention is operable using any device that isoperable to perform browsing of a network including the Internet, butalternative embodiments are envisioned that facilitate mark-ups ofreports or screens for delivery to non-browser based environments. Usinga browser means there are no client side plug-ins or unique training orsupport required for the client environment. Users need only know how touse a browser, and a host of formats are “browser friendly.” Plug-insfor unique formats can be implemented either on the server or on thebrowser.

[0063] Another standard feature of the current implementation is that itallows conversion from traditional formats such as ASCII or MFD, forexample, to a proprietary format that allows single page serving andviewing of reports up to one million pages in total length. This formatalso allows introduction of features not found in source formats such asintroduction of filters, export to Excel, and use of PDF features.Filters can help large reports aggregate data in reports in meaningfulway, and features like indexing and search help users locate criticalinformation in ways not supported by legacy systems. Conversions betweenformats are provided for increased user flexibility. A number ofavailable platforms that are operable to provide these basic functionsmay be used for incorporation into the present invention.

[0064] As mentioned above, one embodiment of the present invention isshown in the FIG. 1. Further details of this embodiment are more fullydescribed below. FIG. 1 is a system diagram of an enterprise-scale,non-invasive report mark-up system 100 built in accordance with thepresent invention. One aspect of the present invention resides in theDeveloper Workbench 20, but certain functionality can be embedded withinanother selected platform in various embodiments. The Report PortalApplication 40 is a generic label for a series of required or desiredfunctions that facilitate or enable the implementation of the invention;a number of rules based applications may be suitable platforms to hostthe invention.

[0065] The system 10 includes, among other things, a developer workbench20 integrated with a report portal application 40, sometimes referred toas a web based enterprise report portal 40. The report portalapplication 40 captures a traditional financial report from a legacysystem environment 12 and provides the report to the developer workbench20. For example, an ASCII report expressed in legacy currency may becaptured by the report portal application 40 from the legacy systemenvironment 12 and provided to the developer workbench 20 in MicrosoftWORD® or EXCEL® or some other useful format for conversion to EUROcurrency.

[0066] In one embodiment, the functionality of the developer workbench20 includes at least four functional elements, though fewer or morefunctional elements are included in various embodiments of theinvention. Examples of the functional elements include reporttransformation 22, currency conversion 24, programmable business rules26 and an auditability and traceability module 28, as will be describedmore fully hereinafter. If desired, rounding detection 29 and mark-ups30 are also offered as functional elements in the developer workbench 20in various embodiments of the invention.

[0067] Analogously, the report portal application 40 includes at leastfive functional elements in one embodiment, though fewer or morefunctional elements are included in various embodiments of theinvention. Examples of the functional elements include report captureand management 42 including format transformation (e.g., to MicrosoftWORD®, EXCEL®, PDF or other formats), report access and distribution 44,report versioning, indexing and search 46, report security,administration, etc. 48 and report repository 50. If desired, profiling52, bursting 54, and dynamic reporting 56 are also offered as functionalelements in the report portal application 40 in various embodiments ofthe invention. From one perspective, the report portal application 40 isviewed as performing the function of a virtual information store in anynumber of desired formats.

[0068] In one embodiment, the Administrator is a special class of userof the report portal application 40 with unique privileges, such as soleread/write access to the developer workbench 20. There may be only oneAdministrator or there may be many Administrators, depending on theparticular business enterprise and the reliance of its legacy systemenvironment 12 on the changeover to the EURO currency. Alternatively,the desktop workbench 20 functionality may be provided to a designatedoperator responsible for report output for a given legacy systemenvironment application, thereby placing the functionality of thedesktop workbench 20 in the hands of the individual responsible fordeveloping the report. In yet another alternative embodiment, any numberof users may be provided with access to the functionality of the desktopworkbench 20. However, in this alternative embodiment, the desktopworkbench 20 is more tightly integrated with the report portalapplication 40 so that the users have access to the functional elementsof the report portal application 40 necessary for the formattransformation and publication of reports.

[0069] Alternatively, a report portal application 40 need not beutilized at all. In such case, however, certain functional elements mustbe added to the developer workbench 20. The essential elements that mustbe added to the desktop workbench 20 include a simplified report captureand management functionality and a simplified report formattransformation functionality for capturing the traditional financialreport and converting it to a more manageable and useful format, such asMicrosoft WORD®, EXCEL®, PDF or other formats. The output from thedesktop workbench 20 can then be stored in various media or output to ahard copy printer. Progressively, functionality may also be added toprovide simplified report access and distribution of the captured,transformed and converted reports to other users. In certain simplifiedscenarios utilizing a middleware reporting layer, such as thatillustrated in the FIG. 1, it may not be necessary to have reportbursting or other complex functionality to perform the most basicnon-invasive techniques for implementing the requirements of the EUROConversion Transition Period.

[0070] Further details of many of the aspects of the developer workbench20 built in accordance with the present invention as shown in theembodiment of the FIG. 1 are described below.

[0071] Developer Workbench 20. This term describes all of theAdministrator functions, both those required to implement unique EUROfunctionalities as well as those underlying functionalities required tocapture, manage, and store secure electronic reports from the legacyenvironment and distribute them across the internet to a browser basedclient set. The Administrator uses these features to profile reports, toimplement the required markup functions, and to ensure the proper flowof information across the enterprise. Sub elements of the DeveloperWorkbench broadly include the following:

[0072] Report Transformations 22. This refers generally to changes inreport formats themselves that may include conversions to proprietaryformats, or from one standard format to another to gain some advantageor features not available to the original source report or to theenvironment that produced it. Examples would be conversion to an Excel,Word, PDF or some other format to gain expanded flexibility for users.

[0073] Currency conversion 24. Currency conversions deal with the stepsnecessary to select the fields in a report that are to be converted andto effect this change. It includes accessing exchange rates from tablesor remote sources such as web sites and applying the correct rates tospecific data, using whatever business rules have been designed for thetimeframe and transaction in process.

[0074] Business Rules 26. Business rules include the entire spectrum ofrules prescribed by law such as Triangulation, no inverse conversion,rounding rules etc, as well as business rules selected by the enterpriseor agreed between trading partners. For example, a business rule mightbe to add currency labels in converted currency fields.

[0075] Auditability module 28. Because in its full implementation, thesource databases are not converted, currency records always match theiraudit documentation and the record of auditability is preserved. Changesoccur within the system and each step of the profiling process isrecorded as an audit log. Software is under configuration management,administrators are known, and each action is noted, including thebusiness rules selected and employed.

[0076] Rounding Error Detection and Correction 29. Introduction ofrounding errors during currency conversion are allowed under the rules,and occur inevitably. The invention provides an automated capability todetect certain rounding errors and to report them to users oradministrators in the form of audit logs or annotations to the report.

[0077] Mark-ups 30. Mark-ups include a series of tools generallyincluding exclusions, hyperlinks, annotations or comments, and a numberof other options for currency conversions. In this case, annotationsinclude any automatically generated or manually inserted comments into areport that concern the conversion or translation process. Hyperlinksare inserted as an aid to move a report or any information contained ina report to another location or to link to a derived report such as anaudit log or rounding error report. Hyperlinks may be utilized toimplement interoperability or phased implementations, as convertedinformation in a target report may be hyperlinked to another applicationthat requires such data as an input. Lastly, Currency Conversions are aclass of Mark-up that is specifically detailed above, that deal with amyriad of issues in changing from legacy currency to Euro, or some othercombination for the enterprise environment.

[0078] Further details of many of the aspects of the web basedenterprise report portal 40 built in accordance with the presentinvention as shown in the embodiment of the FIG. 1 are described below.Again, using the Developer Workbench 20, it is envisioned that screens,queries or reports could be marked up and delivered to otherenvironments that do not use browsers, yet are operable to receive suchscreens, queries or reports.

[0079] Web based Enterprise Report Portal 40. This is a general titlethat describes a set of functionalities that may exist in varyingdegrees, and that form the platform upon which EURO and other reportconversion functionalities and non-invasive enterprise informationaccess and distribution applications can be built. Other platforms thatoperate as rules engines and have sufficient scalability may be suitableas well. This is the functionality that remains in place after the EUROis the sole currency, enabling historical data access and enterprisereporting for all manner of applications. Included in these features arethe following:

[0080] Report Capture and Management 42. This covers the process ofcapturing information in the form of reports that were originallycreated in a legacy system environment. It includes various processesrequired to manage the use of these source reports, and by extension,converted target reports for users or system interoperability.

[0081] Access and Distribution 44. Access is secured at the deepestlevels of the operating system. Any authorized user can obtain access tothe enterprise information he requires, whenever and wherever herequires it. In an alternative embodiment, there is no electronicdistribution, but the converted reports are distributed in the manner inwhich the distribution that they are today, before the use of such anelectronic delivery system.

[0082] Versioning, indexing, search 46. Capability is provided to retainversions of reports. Reports are indexed and robust search capabilitiesare included so that users may search reports or content to find exactlythe information they require.

[0083] Security, administration, etc. 48. Depending upon the selectionof platform for use in the present invention, a robust solution forproviding user based and role-based security can be it provided. Thecurrent implementation of the invention utilizes NT as an operatingsystem and therefore leverages this embedded organizational structurefor security. Only users who have security authorization can receivereports using such systems.

[0084] Report Repository 50. The repository stores meta-data, which isdata about the report traditionally used by reporting systems to managethe reports. It also includes the reports themselves, complete withcompanion audit log, annotations, etc. Either or both of the sourcereport and the target report may be stored here, in whatever formats areselected. Or, for example, the source report may remain in the legacyenvironment if distribution is not needed, or to conserve storage space.

[0085] Profiling 52. Profiling has been described elsewhere in thisapplication including “Use of the Report Profile” above.

[0086] Bursting 54. The operation of the burster has been describedelsewhere in this application. This is one way to leverage the live datathat is utilized by the burster to break up reports. The Burster may beused as a platform to implement various mark-ups within the reports.(See above)

[0087] Dynamic Reporting 56. Mark-ups can be implemented on traditionalstatic reports, as well as on dynamic reports or queries using reporttemplates where users can make queries and dynamic converted reports areobtained in near real time. The templates are profiled and when thedynamic report arrives in the system directory for processing, theprofile is called and conversions are implemented from the profile tocreate the dynamic target report. In certain embodiments of theinvention, these reports can be created using the Developer Workbench 20and with or without browsers.

[0088]FIG. 2 is a functional block diagram illustrating an embodiment ofa method 200 performed in accordance with the present invention. Themethod 200 includes the steps necessary to publish and capture atraditional financial report expressed in the legacy currency, sometimesreferred to as the “source report,” and to transform and convert theSource report into a corresponding report expressed in the EUROcurrency, sometimes referred to as the “target Report.” As illustratedmore specifically in the FIG. 2, the legacy system environment system 12publishes the source report to the report portal application 40 or theweb based enterprise report portal 40 (step 102). Using the desktopworkbench 20, the Administrator profiles the source report, therebycreating a source report profile (step 104). The source report profilemay be created in advance of the publication of the Source report or maycreated the first time that the Source report is published to the reportportal application 40. Regardless, the source report profile preferablyis created only once and is thereafter utilized in a “lights out” batchprocessing mode to automatically convert future versions of the samesource report to a corresponding target report as previously described.

[0089] Once the source report profile has been created, the reportportal application matches the source report profile to the sourcereport (step 106) and runs the source report profile on the sourcereport (step 108) to generate the target report. Thus, the target reportis the EURO currency report that results from the conversion of thesource report using the source report profile.

[0090] As mentioned above, this process is accomplished in a “lightsout” manner without human intervention once the source report profilehas been created for a particular source report. The report portalapplication 40 then stores the source report and the target report inthe report repository 50 (step 110) and distributes the target report asspecified by the Administrator (step 112). Of course, the source reportis available to be distributed as well by the report portal application40 as specified by the bursting profile established by the report accessand distribution 44 functionality.

[0091] Other Aspects and Features of the Present Invention. Some or allof these features will be present depending upon embodiment and platformselection.

[0092] Non-Invasive to legacy systems and processes. This means that toget information out of legacy enterprise information stores, there is noneed to modify the legacy databases, which can be particularly difficultin both old systems as well as more modem relational databases. Thismeans that it does not matter if there is hard coding, limited fieldwidth, lack of labeling for currency or other reasons in the legacydata, since it is the data, not the underlying legacy programming, thatis important to this solution.

[0093] User driven and controlled. The business manager can select theproper form and format of required information, as well as selecteddata, to form a new report derived from the underlying legacy-reportingenvironment. For example, depending upon the choice of platform,information can be gathered from multiple source reports/databases andconsolidated in a single target Excel workbook, which can be furtherrefined or enhanced, then published to the organization or individualmembers. Information from large reports can be served to an individualone page at a time to reduce bandwidth requirements.

[0094] Platform Independent Design. This aspect of the present inventionoffers a distinct advantage over traditional approaches. The solution isscalable across an enterprise and does not depend upon the hardware orsoftware platforms from which information is accessed. This means thatit can scale across platforms, from one to many, without the need forcustom interface software modules. Virtually any enterprise data can becaptured and converted using standard report formats from any underlyinglegacy environment.

[0095] Date Based Rules. Rules based conversions where DATE of recordcreation can be the rule. The system automatically can be programmed touse a set date or scan the report for a custom date to be selected. Itis also possible for the system administrator to insert dates intospecific legacy reports to support mark-up using aspects of the presentinvention. This date is used to identify the correct currency conversionrates to be used in particular data. In addition, multiple dates can beselected per a given report, allowing conversions at different exchangerates to be used on unique data sets within the same report or system.

[0096] a. The solution allows for mixed data to co-exist on samedatabase as input to the solution, and to format the output correctly asdesired, including the use of labels etc. An example would be for adatabase that has multiple currencies, whether it has labels or not. Thetarget reports may be profiled to allow for a currency label or variablewidth field to be inserted, when the original report or database doesnot allow this.

[0097] b. Settings can be selected as a default or at the time ofinitial report profiling. These unique dates can be set for anorganization, system, or report to ensure the correct rate is applied toall historical or current data.

[0098] c. Users may select the time of conversion of data to minimizebusiness risk and disruption. For example, this may mean that one systemmay have a different cutover date than other systems, and the derivedreports for that application may be treated independently. The abilityto have mixed data able to co-exist on the database with safety allowsfor the separation of conversion from transition and migration, asdescribed earlier in this document. This is yet another area wherecertain aspects of the present invention depart from tradition methods.

[0099] d. Use of this feature MAY avoid need for parallel bookkeepingthrough the transition year. You may use the same set of data and beassured the exchange rates are correct regardless of the date.

[0100] Source Based Rules. These are rules where the SOURCE of data canbe the rule.

[0101] a. Source based rules are important where there are mixedcurrency sources (from multiple distributed applications). These can bepresented in the required output format using the multiple toolsprovided.

[0102] b. Source base rules allow organizations to phase conversions ofinteroperating systems at different times. This means conversion can beone system at a time, or in any order. Converted data is known forexample to be in EURO and may be provided to other applications that areinterconnected and that require converted input in EURO.

[0103] c. These features allow users to set conversion dates with acrossinternal and external enterprise boundaries without changes tounderlying legacy applications.

[0104] Support for multiple distribution media. Output may be providedvia electronic file, paper, screen or web based presentation.

[0105] Scalability. The solution is scalable from small businesses (NTPC based) to large enterprises (multiple NT server). Scalableperformance means scalable investment.

[0106] Residual value. Unlike other solutions, it leaves behind valuewhen currency conversion is over. It remains in place as a reportingplatform for historical and other purposes. In addition, there is anexisting support infrastructure in place and a product developmentroadmap.

[0107] Fast implementation. The system can be quickly deployed withoutthe need for extensive external resources by training existing legacysystem administrators.

[0108] Flexibility and control. Aggregation of all unique functionalityin a central location for the enterprise means increased flexibility andcontrol to implement changes. Software is under configuration managementand all changes on individual reports are logged for trace ability.

[0109] Future Supportability. Uses only industry standard languages andproducts such as NT, VB, asp and XML to provide assurance of futuresupportability. Use of a platform is a unique approach to this problem,and use of a platform that is general purpose ensures ongoingdevelopment and support, yet adding even further value.

[0110] Interoperability. Capability is provided to enable systems towork with systems that may have been independently EURO-enabled, forexample by vendors. Data from the converted reports from one system maybe provided to other applications that required EURO input. Keysupported techniques include XML, hyperlinks, annotations, and asppages, depending upon the platform selected.

[0111] Elimination of Coding Errors. Because legacy systems are notrenovated, there are no coding errors in the legacy system.

[0112] Maintenance of Auditability. Source data stays in the form of thesupport documentation. Coupled with no errors, this means that the audittrail is maintained. Conversions in the reporting environment maintain alog of actions and version of software utilized.

[0113] Detection and Correction of Rounding Errors. The solutionincludes capability to detect rounding errors as permitted byregulation, and to identify certain errors for correction byadministrative personnel.

[0114] Post Processing Solution. Many current approaches add conversionfunctionality into existing legacy systems, increasing complexity andprocessing overhead. This solution offloads that functionality andoutput functions to improve performance and flexibility.

[0115] Dynamic Reporting. This system provides not only the ability tomark up static reports from structured materials, but also to performmark ups on dynamic reports such as queries or screens. Typicallytemplates are defined and profiled for dynamic query. The user selects atemplate, makes the appropriate query, then runs the report. The reportenters the reporting system where the profile is matched and run,producing the converted EURO report for access by the user in nearrealtime.

[0116] Security. The system provides for user level and role basedsecurity, in the present case using and leveraging the NT securitysystem and LDAP techniques. This means that the information is providedonly to specific individuals who have a need to know, which isparticularly important for Internet delivery systems.

[0117] PDF Forms. Some platforms provide a capability for applicationsthat may have used many forms to provide applications such as customerbilling. Instead of expensive archiving of forms, a capability isprovided that allows separation of the forms from the data, so that thedata can be stored in traditional files and a key will match it to a setof forms which are stored separately. In this manner, a Telco who hasmillions of bills using 50 different forms could significantly reducestorage by storing only the data. The system automatically knows thatfor a particular customer in a given month a certain form was used, andupon requests pulls the data and the form to provide to the customer.Storing 50 instances of the form is much more efficient that storingimages of a million transactions.

[0118] Archiving Capability. This system has significantly reducedarchiving capability since historical data stays in legacy currency andis converted on demand and not duplicated in converted form, thusrequiring duplication of storage. In addition the electronic catalogingand indexing of reports and enterprise information means that it is muchmore efficient to retrieve materials. Historical data can be stored inoptical media and immediately retrieved if it has been catalogued andindexed as described. Hence the system also provides archivingcapability.

[0119] Proprietary formats and Format conversion. The present inventionis able to leverage capabilities found in some platforms that includes aproprietary conversion process typically done on ASCII or MFD files.This enables very large reports up to 1 million pages to be efficientlyserved one page at a time upon demand, with acceptable performance evenin a dial up environment. It also provides other very useful featureslike allowing filters to be embedded in reports to facilitate use andgarnering of critical information. Using this format it is also able toprofile an export of the report to Excel, or to use PDF formscapability. Excel workbooks may be created with pages from separatereports for example, which legacy systems do not typically support.

[0120] Report Mark Ups. As mentioned previously, mark up is anotheraspect of the present invention that obviates the need for renovationand invasive procedures in legacy database applications. Mark up enablesusers to extract information from databases in the form of reports, andto perform all manner of conversions and transformations on the reportto make it suitable for users or other systems that may requiredifferent inputs.

[0121] From certain perspectives, one embodiment of the presentinvention is found in a system and method for implementing the temporaryand unique requirements of the EURO Conversion Transition Period. Theinvention isolates the requirements of the Transition Period andimplements them in a powerful middleware (as defined previously herein)reporting layer that is non-invasive to the existing legacy systemenvironment. Underlying applications and databases remain in localcurrency, also referred to herein as legacy currency, therebymaintaining auditability and traceability, and eliminating the need forhistorical conversion and reconciliation of the data within the legacysystem environment databases. Of course, the existing legacy systemenvironment must still be modified to accommodate and process the EUROcurrency. However, the need to make massive, invasive changes to theunderlying applications and existing databases, for example to providesix significant digits and to perform permissible rounding andtriangulation, is substantially eliminated. Accordingly, changes to thelegacy system environment applications and databases are simplified andminimized. The system and method of the present invention furtherincludes means for automating the detection and correction of permittedrounding errors introduced by the changeover to the EURO.

[0122] As a result, the legacy system environment can continue to beused throughout the Transition Period without a noticeable effect on theprocesses. Standard, pre-defined reports may be generated in the samemanner as before, while EURO reports derived from the pre-definedreports are created and distributed. And because IT directors andmanagers are forced to implement a Transition Period solution beforetheir company's business requirements are fully ascertained, isolationof the temporary and unique requirements in a single middlewarereporting application can also provide much needed flexibility and speedin reacting to new and changed requirements both during and followingthe Transition Period.

[0123] Furthermore, use of the non-invasive middleware-reporting layerof the invention supports re-engineering of applications and databasesduring implementation of the requirements of the EURO ConversionTransition Period by providing embedded functionality for widespreadsecure electronic access of standard reports to Internet/Intranet users.Thus, even when the EURO Conversion Transition Period is past, theinvention will remain in the IT infrastructure to provide an extensible,multi-purpose platform for increasing e-commerce initiatives.

[0124] From other perspectives, the present invention is viewed as asystem and a method that is operable to avoiding the introduction ofmassive, invasive procedures in the underlying legacy system environmentapplications, processes and existing databases where reporttransformation and financial conversions are required. More specificallyin one particular application of the present invention, it possible toperform report transformation and currency conversion necessitated bythe changeover to the EURO during the temporary and unique requirementsof the EURO Conversion Transition Period. In the invention, thetemporary and unique requirements associated with the EURO currencytransactions are capable to be isolated in a middleware reporting layerso that the existing management reports are transformed and the currencyconversion occurs within the middleware. This isolation eliminates theinvasive techniques required to expand or modify existing databasefields in the underlying legacy system environment applications.

[0125] The present invention utilizes existing management reports, whichare transformed, converted and then re-published to the reportrepository for distribution to Internet/Intranet users in thetraditional, secure environment. Both the original and converted reportsare stored in the report repository. Accordingly, either report can beaccessed and viewed in the desired currency. In addition, the inventionprovides the auditability and traceability that is essential whendealing with financial information. The approach of the invention leavesfinancial information, and in particular numerical figures, in theunderlying database untouched, consistent with all backup documentation,so that complete auditability and traceability is maintained with dataand documentation in original, unchanged form. Changes made in themiddleware reporting layer are recorded in a robust external auditsystem including logs, comments and associated documentation.

[0126] Isolation of the temporary and unique requirements of the EUROConversion Transition Period in the middleware reporting layer hascompelling value propositions not found in any proposed, conventional,alternate solutions. These value propositions provided by the presentinvention include:

[0127] An entirely non-invasive approach to applications, processes andexisting databases of the legacy system environment (assuming that theunderlying system can accept the EURO as an alternate currency).

[0128] Complete and robust auditability and traceability with graphicaltools, annotations and hyperlinks to source documents and reports.

[0129] Historical data restatement can be done in traditional reportsexpressed in the EURO currency, without manual restatement,reconciliation or use of parallel systems.

[0130] New and changed requirements can be easily and quicklyimplemented in one step, rather than by manual, separate re-coding stepsin numerous applications.

[0131] Access to timely information and electronic reporting offinancial documents can be implemented with substantial cost savings,thereby meeting the rapid response requirements necessitated by thecontinued emergence of e-commerce activities.

[0132]FIG. 3 is a system diagram illustrating an embodiment of reportprocessing 300 performed in accordance with the present invention. Alegacy system 310 is operable to generate a legacy system report 311.The legacy system report 311 is provided to a middle-ware applicationlayer (MWAL) 320 in any number of ways. It is electronically printed(e-printed) directly over an existing network in one embodiment. Thenetwork is the Internet itself in certain embodiments of the invention.If desired, the e-printing is performed using any number of desiredprofiles that controls non-invasive mark-up of the legacy system report311 itself during the e-printing from the legacy system 310 to the MWAL320 over the network. The e-print of the legacy system report isperformed using a legacy e-print profile as shown in the process block370. Alternatively, the e-print of the legacy system report is performedusing some other e-print profile as shown in the process block 371. Asystem administrator has the option to modify the legacy system report311 to make it more “friendly” to the MWAL 320 for any subsequentmark-up processing. However, this application is not always necessary,as the MWAL 320 can nevertheless accommodate the legacy system report311 in whichever format provided. However, the system administrator ofthe legacy system 310 is able to modify the legacy system report 311itself or a legacy e-print profile that is used to govern the e-printingof the legacy system report 311 without compromising the functionalityof the report processing 300.

[0133] Once the legacy system report 311 is e-printed to the MWAL 320,it is viewed as being a legacy system e-report 312 within the MWAL 320.Using a profile 319, the legacy system e-report 312 is marked-up togenerate a modified legacy system e-report 313. From certainperspectives, the modified legacy system e-report 313 is viewed as beinga virtual e-report that is a modification of the legacy system e-report312 within the MWAL 320. If desired, the modified legacy system e-report313 is automatically generated and transmitted back to the legacy system310 over the network. Alternatively, the modified legacy system e-report313 is stored in a memory 380 located within the MWAL 320.

[0134] The mark-up functionality and processing on the legacy systeme-report 312 within the MWAL 320 includes any number of differentprocessing as described above in various embodiments of the invention.In one embodiment, the processing includes performing currencyconversion from the national currency used in the legacy system 310 andthe legacy system report 311 to a different currency. This differentcurrency is the new EURO currency used in much of Europe today. However,the present invention offers the functionality that the mark-upprocessing is capable to be performed on the legacy system e-report 312without requiring any backward compatibility with the MWAL 320 itself.Different currencies can be used by any number of legacy systems withoutcompromising the performance of the report processing 300. Other mark-upprocessing may be performed besides currency conversion as well. Anynumber of processing functions may be performed where conversion of someor all of the data used in legacy systems is desired to be transformedto a new standard. Moreover, the present invention is also operable toprovide for those instances where different legacy systems are to bemodified using different profiles.

[0135] Any other user system 350, having permission to do so, may accessthe modified legacy system e-report 313. From certain perspectives, theother user system 350 is another legacy system. However, the other usersystem is simply a user interface capable to access the MWAL 320 inother embodiments. Therefore, in some instances, the modified legacysystem e-report 313 is viewed as being an e-report corresponding to theother user system 350 itself. As mentioned above, the MWAL 320 providesfor the modified legacy system e-report 313 to be transmitted back tothe legacy system 310 (or the other user system 350) immediately uponbeing generated. In embodiments where the modified legacy systeme-report 313 is not sent back immediately, or after some period of time,the other user system 350 is able to request the modified legacy systeme-report 313 as shown in a process block 321. This request is sentdirectly to the MWAL 320.

[0136] The modified legacy system e-report 313 is provided to the otheruser system 350 in any number of ways. For example, a reportcorresponding to the modified legacy system e-report 313 is actuallygenerated “on the fly” in one embodiment as shown by the arrow 321. Insuch a situation, the legacy system e-report 312 is processed, at thetime the request is made by the other user system 350. The reportprocessing of the legacy system e-report 312 is performed in response tothe request. In addition, a profile 349 is used to control thee-printing of this newly-generated report, generated from the legacysystem e-report 312, as it is provided to the other user system. Theprofile 349 and the profile 319 are a similar profile, or a commonprofile in various embodiments of the invention; however, they aredifferent profiles in others.

[0137] Alternatively, in embodiments where the modified legacy systeme-report 313 is generated and stored in the memory 380, the request bythe other user system 350 to the MWAL 320 initiates the transfer of themodified legacy system e-report 313, that is stored in the memory 380,to be transmitted to the other user system 350. Similarly, this transferis performed using a profile 339. Also similarly, the profile 339 andthe profile 319 are a similar profile, or a common profile in variousembodiments of the invention; however, they are different profiles inothers.

[0138]FIG. 4 is a system diagram illustrating another embodiment ofreport processing 400 performed in accordance with the presentinvention. A legacy system # 410 is operable to generate a legacy system#1 report 411. The legacy system #1 report 411 is provided to amiddle-ware application layer (MWAL) 420 in any number of ways. It iselectronically printed (e-printed) directly over an existing network inone embodiment. The network is the Internet itself in certainembodiments of the invention. If desired, the e-printing is performedusing any number of desired profiles that controls non-invasive mark-upof the legacy system report # 411 itself during the e-printing from thelegacy system # 410 to the MWAL 420 over the network. The e-print of thelegacy system report is performed using a legacy #1 e-print profile asshown in the process block 471. A system administrator has the option tomodify the legacy system #1 report 411 to make it more “friendly” to theMWAL 420 for any subsequent mark-up processing. However, thisapplication is not always necessary, as the MWAL 420 can neverthelessaccommodate the legacy system #1 report 411 in whichever formatprovided. However, the system administrator of the legacy system #1 410is able to modify the legacy system #1 report 411 itself or a legacye-print profile that is used to govern the e-printing of the legacysystem #1 report 411 without compromising the functionality of thereport processing 400.

[0139] Similarly, any number of other legacy systems, shown as legacysystem #2 420, . . . , and legacy system #N 490 are each operable togenerate legacy system reports, shown as legacy system #2 report 421, .. . , and legacy system #N report 491. The e-printing of these legacysystem reports to the MWAL 420 is direct in some embodiments of theinventions, and it is performed using a legacy e-print profile, as shownby legacy #2 e-print profile, . . . , legacy #N e-print profile as shownin the process block s 472, . . . , and 479.

[0140] Once the legacy system #1 report 411 is e-printed to the MWAL420, it is viewed as being a legacy system #1 e-report 412 within theMWAL 420. Using a profile #1 419, the legacy system #1 e-report 412 ismarked-up to generate a modified legacy system #1 EURO e-report 413.From certain perspectives, the modified legacy system #1 EURO e-report413 is viewed as being a virtual EURO e-report that is a modification ofthe legacy system #1 e-report 412 within the MWAL 420.

[0141] Similar to the functionality proffered by the various embodimentsof the invention shown above, if desired, the modified legacy system #1EURO e-report 413 is automatically generated and transmitted back to thelegacy system 410 over the network. Alternatively, the modified legacysystem #1 EURO e-report 413 is stored in a memory located within theMWAL 420. The accessing and retrieval of the modified legacy system #1EURO e-report 413 is performed using any of the methods mentioned above,including retrieving it from memory or having it be generated “on thefly” in response to a request for a report representative of the legacysystem #1 e-report 412.

[0142] In addition, each of the other legacy reports may undergoadditional processing similar to the legacy system #1 e-report 412 usingthe profile #2 429, . . . , and the profile #N 499. If desired, themark-up and report processing of the legacy system e-reports may beperformed using a common profile 409 in some embodiments of theinventions. For example, the common profile 409 could be a defaultprofile generated automatically by the system before a SystemAdministrator adds unique Mark-Ups.

[0143] The report processing 400 is demonstrative of the capability ofthe present invention to accommodate any number of different legacysystems and perform mark-up processing on them using profiles thatindependently correspond to those legacy systems. However, the presentinvention is operable to perform report processing that is common to allof the legacy systems, such that control and flexibility are enhanced,unlike alternatives that require unique changes for each system.

[0144] As disclosed by the modified legacy system EURO e-reports 413,423, . . . , and 493, the modification and mark-up processing of thelegacy system e-reports 412, 422, . . . , and 492 includes currencyconversion from any one or multiple national currencies corresponding tothe legacy systems to the EURO. The present invention allows for thelegacy systems to maintain their legacy system reporting using thenational currencies without needing to dedicate and utilize processingresources on their end to perform this currency conversion processing.All processing envisioned by the present invention can be performed inthe MWAL 420, typically on a NT or other suitable server. The presentinvention allows for an enterprise-scale implementation where any numberof legacy systems may interface to the MWAL 420 to perform reportprocessing that may include converting some of the data, reported in oneformat within the report, to a new format within another report.

[0145] From certain perspectives, the report processing shown above inthe FIGS. 3 and 4 is performed on screens of the legacy system reports.Screens are really structured information that are real-time reports;they can be profiled and converted within the scope and spirit of thisinvention by numerous means. For example, when the legacy system reportis provided, the report processing is performed at that time and inresponse to the data given at that particular point in time. Theworkbench would create a profile for each screen or query and run itwhen the completed request arrives from the database; it would then runthe profile and return the transformed information back to therequester.

[0146]FIG. 5 is a system diagram illustrating an embodiment of profileprocessing 500 performed in accordance with the present invention. Theprofile processing 500 generically illustrates the transformation of alegacy system e-report 512 to a legacy system EURO e-report 513. Thereport processing shown in the FIG. 5 shows how the profile 501, thatmay be contained in a middle-ware application layer (MWAL), as shown invarious embodiments of the invention, to control the mark-up and otherprocessing performed within the profile processing 500 as determined bya system administrator. The legacy system EURO e-report 513 containssimilar information as in the legacy system e-report 512 except that allof the currency information is converted from the currency standard inthe legacy system e-report 512 to the EURO currency standard. The legacysystem e-report 512 need not itself be in EURO currency format.

[0147] One aspect of the present invention provides for accommodation ofthe legacy system e-report 512 when it contains currency informationthat is already in EURO format. The profile processing 500 that employsthe profile 501 is able to accommodate this situation and pass theEURO-based information unchanged in one legacy system (that is alreadyoperating using the EURO) and still accommodate the modification mark-upand other processing from a national currency to the EURO in anotherlegacy system (that has not yet made the transition to the EURO). Use ofrules and retaining the legacy System Administrator in the loop ensurethat these mark-ups can be done effectively without error.

[0148]FIG. 6 is a system diagram illustrating another embodiment ofprofile processing 600 performed in accordance with the presentinvention. The profile processing 600 is a variation of the profileprocessing 500 shown above in the FIG. 5. The profile processing 600illustrates the transformation of a legacy system e-report 612 to anumber of legacy system EURO sub-e-reports, as shown by a legacy systemEURO sub-e-report #A 613, a legacy system EURO sub-e-report #B 614, . .. , and a legacy system EURO sub-e-report #M 616; this illustrates, forexample, how a Burster may parse and create separate reports, which insome embodiments may have unique profiles.

[0149] A profile 601 is used to control the mark-up and reportprocessing of the legacy system e-report 612 into the legacy system EUROsub-e-reports 613, 614, . . . , and 616. A parser 602 is used tosub-divide certain portions of the legacy system e-report 612 into thelegacy system EURO sub-e-reports 613, 614, . . . , and 616. The legacysystem EURO sub-e-reports 613, 614, . . . , and 616 are each similar insize and content fields in one embodiment, and they are independent anddifferent in other embodiments.

[0150] Alternatively, a burster 690 is employed to perform thetransformation of the legacy system e-report 612 to a number of legacysystem EURO sub-e-reports, as shown by the legacy system EUROsub-e-report #A 613, the legacy system EURO sub-e-report #B 614, . . . ,and the legacy system EURO sub-e-report #M 616. The burster 690 isoperable to contain a profile 691 and a parser 692 in certainembodiments of the invention. Here, a separate module, that is externalto a report processing system in one embodiment, and integrated withinthe report processing system in another embodiment, is used to performboth the control of the mark-up and report processing on the legacysystem e-report 612 as well as the parsing of the legacy system e-report612 into the legacy system EURO sub-e-reports 613, 614, . . . , and 616.

[0151] The FIG. 6 is illustrative of some of the variations by which thelegacy system e-report 612 is transformed into the legacy system EUROsub-e-reports 613, 614, . . . , and 616. Clearly, other manners ofperforming the transformation are also envisioned without departing fromthe scope and spirit of the invention.

[0152]FIG. 7 is a system diagram illustrating another embodiment ofprofile processing 700 performed in accordance with the presentinvention. The profile processing 700 is another variation of theprofile processing 500 shown above in the FIG. 5.

[0153] The profile processing 700 illustrates the transformation of alegacy system e-report 712 to a modified legacy system e-report (in EUROformat) 713. The modified legacy system e-report (in EURO format) 713has an indefinite number of sub-portions, shown as a legacy system EUROsub-portion #A 714, a legacy system EURO sub-portion #B 715, . . . , anda legacy system EURO sub-portion #L 717. A profile 701 is used tocontrol the mark-up and report processing of the legacy system e-report712 into the modified legacy system e-report (in EURO format) 713 havingthe various sub-portions 714, 715, . . . , and 717. A parser 702 is alsooperable to subdivide certain portions of the legacy system e-report 712into the various portions 714, 715, . . . , and 717. The sub-portions714, 715, . . . , and 717 are each similar in size and content fields inone embodiment, and they are independent and different in otherembodiments.

[0154] Alternatively, a burster 790 is employed to perform thetransformation of the legacy system e-report 712 to the modified legacysystem e-report (in EURO format) 713 having the indefinite number ofsub-portions, shown as a legacy system EURO sub-portion #A 714, a legacysystem EURO sub-portion #B 715, . . . , and a legacy system EUROsub-portion #L 717. The burster 790 is operable to contain a profile 791and a parser 792 in certain embodiments of the invention. Here, aseparate module, that is external to a report processing system in oneembodiment, and integrated within the report processing system inanother embodiment, is used to perform both the control of the mark-upand report processing on the legacy system e-report 712 as well as theparsing of the legacy system e-report 712 into the modified legacysystem e-report (in EURO format) 713 having the various sub-portions714, 715, . . . , and 717.

[0155] The FIG. 7 is illustrative of some of the variations by which thelegacy system e-report 712 is transformed into the modified legacysystem e-report (in EURO format) 713 having the various sub-portions714, 715, . . . , and 717. Clearly, other manners of performing thetransformation are also envisioned without departing from the scope andspirit of the invention.

[0156]FIG. 8 is a timeline diagram illustrating an embodiment ofcurrency conversion 800 that is capable to be performed in accordancewith the present invention. A number of national currencies, shown as anational currency #1, national currency #2, . . . , and nationalcurrency #12 as well as a national currency #A, national currency #B, .. . , and national currency #N are each undergoing or will undergo atransition from their respective national currency to the EURO currency.A group of the twelve countries, shown as the national currencies 1, 2,. . . , and 12, undergoes transition from their respective nationalcurrencies to the EURO currency during a three year transition periodextending from Jan. 1, 1999 to Dec. 31, 2001. There is a fixed exchangerate guaranteed for each of the countries during the transition period.The exchange rate for each of the national currencies 1-12 is guaranteedduring that three year period.

[0157] Certain other of the other national currencies A, B, C, . . . ,and N perform the transition during the same three year period as thenational currencies 1, 2, . . . , and 12. For example, the nationalcurrency C has a one year transition period on the tail end of the threeyear transition period. The transition period of the various nationalcurrencies 1, 2, . . . , and 12 are of various lengths. For example, thetransition period of the national currency #B is shown to have atransition period that is relatively longer than the transition periodof the national currency #A. As shown by the national currencies #A and#N, the transition periods are capable to extend after the three yeartransition period has expired. The present invention allows for anynumber of additional national currencies to transition to the EURO atany time. The present invention also allows for the addition of anynumber of countries to come into the fold of EURO currency usingcountries at any time after the three year transition period hasexpired, as exemplified by the national currencies #A and #N. The lengthof the transition periods of these national currencies and the exchangerates of these transitions are also variable. The present invention isequally operable to perform transformation from other currencies to acommon currency as well.

[0158] In view of the above detailed description of the presentinvention and associated drawings, other modifications and variationswill now become apparent to those skilled in the art. It should also beapparent that such other modifications and variations may be effectedwithout departing from the spirit and scope of the present invention.

What is claimed is:
 1. An enterprise-scale non-invasive financial reportmark-up processing system, the system comprising: a legacy system thatis operable to generate structured legacy system information having aformat and having financial data corresponding to a first currencystandard; a middle-ware application layer, communicatively coupled tothe legacy system, that is operable to receive the legacy system reportfrom the legacy system via electronic printing thereby generating alegacy system e-report; and wherein the middle-ware application layeremploys a profile to perform mark-up processing on selected portions ofthe legacy system e-report to generate a modified legacy systeme-report; and the modified source e-report comprising financial datacorresponding to a second currency standard.
 2. The system of claim 1 ,wherein the second currency standard comprises a EURO currency.
 3. Thesystem of claim 1 , wherein the middle-ware application layer furthercomprises a burster; and the the burster comprises the profile.
 4. Thesystem of claim 3 , wherein the burster is operable to parse the legacysystem e-report into at least one of a plurality of sub-e-reports and aplurality of sub-portions.
 5. The system of claim 1 , furthercomprising: at least one additional legacy system that is operable togenerate at least one additional legacy system report having at leastone additional format and having financial data corresponding to a thirdcurrency standard; the middle-ware application layer is alsocommunicatively coupled to the at least one additional legacy system andis operable to receive the at least one additional legacy system reportfrom the at least one additional legacy system via electronic printingthereby generating at least one additional legacy system e-report; andwherein the middle-ware application layer employs at least oneadditional profile to perform mark-up processing on selected portions ofthe at least one additional legacy system e-report to generate at leastone additional modified legacy system e-report; and the modified sourcee-report comprising financial data corresponding to a fourth currencystandard.
 6. The system of claim 5 , wherein the profile and the atleast one additional profile are substantially a common profile.
 7. Thesystem of claim 5 , wherein the second currency standard and the fourthcurrency standard both comprise a common currency standard.
 8. Thesystem of claim 1 , wherein modified legacy system e-report is generatedduring a predetermined transition period from the first currencystandard to the second currency standard.
 9. An enterprise-scalenon-invasive financial report mark-up processing system, the systemcomprising: a legacy system that is operable to generate a source reporthaving financial information based on a national currency; a middle-wareapplication layer, communicatively coupled to the legacy system, that isoperable to receive an electronically printed version of the sourcereport and perform non-invasive mark-up processing of the financialinformation based on the national currency within the source report andto convert that financial information to financial information based onthe EURO thereby generating a target report; and a user system,communicatively coupled to the middle-ware application layer, that isoperable to retrieve the target report from the middle-ware applicationlayer.
 10. The system of claim 9 , wherein at least one of thecommunicative coupling between the legacy system and the middle-wareapplication layer and the communicative coupling between the middle-wareapplication layer and the user system comprises communicative couplingvia the Internet.
 11. The system of claim 9 , wherein the electronicallyprinted version of the source report is generated based on an e-printprofile.
 12. The system of claim 9 , wherein the non-invasive mark-upprocessing is performed using a profile; the profile comprises aplurality of processing rules; and the profile is contained within themiddle-ware application layer.
 13. The system of claim 9 , wherein themiddle-ware application layer distributes the target to at least oneadditional user system.
 14. The system of claim 9 , wherein themiddle-ware application layer distributes the target to the user systemafter the user system transmits a request to the middle-ware applicationlayer.
 15. The system of claim 9 , wherein the middle-ware applicationlayer further comprises a burster; and the the burster comprises aprofile.
 16. A method to perform non-invasive financial report mark-upprocessing, the method comprising: creating a source report profile tobe used to process a source report, the source report having financialdata corresponding to a first currency standard; electronicallytransmitting the source report to a middle-ware application layer;processing the source report within the middle-ware application layer togenerate a target report based on the report profile; and generating amodified source report, the modified source report having financial datacorresponding to a second currency standard.
 17. The method of claim 16, wherein the second currency standard comprises a EURO currency. 18.The method of claim 16 , wherein the target report is generated inresponse to a request provided by a user system.
 19. The method of claim16 , wherein the target report comprises a plurality of sub-portions.20. The method of claim 16 , wherein the target report is parsed into aplurality of sub-e-reports.